With the advent of the Internet, massive amounts of data are becoming more accessible to large number of users, whether in internal corporate environments or in the public arena such as web-based databases. Accordingly, more efficient and performance-driven requirements are being placed on such systems as the number of user, and consequently, the number and complexity of queries continues to increase.
In a relational database management system, as an example, relationships between data (or files) are created by comparing data, such as account numbers and names. The data being compared and the results can be structured in the form of tables. A join process includes matching records in one table (or file) with records in another, based on some condition, and creating a third table that includes data from the tables being joined. In one example, an Order table can be joined with a Customer table to create a third table for all customers who purchased a particular product.
The default type of join is the inner join, which produces a resulting record whenever two records, one from each input table, satisfy the matching condition. Consider another example that matches shipments with receipts. The join would produce a table of shipments that have been received but omit shipments that have not been received. Contrariwise, an outer join would create a table of every shipment, whether or not it was received. Data for received items is attached to the shipments. Empty (or null) fields would be attached to shipments without receipts.
Materialized views, also called indexed views, are a mechanism for speeding up processing of database queries. A materialized view is a precomputed result that may be used to compute part or all of query instead of computing it directly from base tables. Materialized views can provide dramatic improvements in query processing time. To be useful, a materialized view must be updated when any of its underlying base tables is updated. This is normally referred to as view maintenance. Efficient, incremental view maintenance algorithms are currently known only for SPJG views, that is, views composed of select, project and inner-join operators, with an optional aggregation operator on top, the aggregation operator summarizing the results of the query.
Prior work on incremental maintenance of materialized views has focused primarily on SPJG views but one conventional system provides a mechanism for maintaining outer-join views. However, it does not cover aggregated views, and the mechanism may become grossly inefficient for views with more than a single outer join.